原帖 ｜ Jason ｜ 2026-09-02 10:26 ｜ 👍0 ｜ 阅读约1
分享一下企业真实的 Linux 驱动/BSP 问题闭环流程，也是日常最标准的工作流。
代码都是三分写，七分调，这个在 Linux 驱动行业体现的尤其明显。
Linux 应用程序你可以随便写，崩了也不影响系统，Linux 驱动代码一个空指针整机都会死机，用户感官很强烈。所以一般情况下我们很少大刀阔斧的改驱动代码，都是一代一代产品迭代过来的，从零写的也很少。
驱动的问题，很多时候你 UT 自测可能测不出来，要大量机器才能测出来，必须依赖产线批量的测试。比如一些多核并发、内存屏障 mb() 这类问题，都是一些很 corner 的时序问题，需要很多机器测很久时间才能出现。【这里所谓时序问题，就是你单纯梳理代码逻辑是发现不了错误的，是多个线程在比较严格的时序情况下才能会结合在一起犯错，是比较难解决的 Linux BUG 种类之一，其次是随机踩内存问题】
因此一般这类问题的解决，流程如下：
1. 稳定复现问题
先固定环境：软件版本、设备树、编译环境、操作步骤。确保问题在一定时间内，靠一定数量机器可复现，比如 100 台机器压测 48 小时出现 2 例，必须有这类数据，这是定位根因的前提。复现不了的话，需要根据线索，设计劣化实验，劣化出来。
2. 分层定位根因
从上到下排查：应用层、内核子系统、驱动代码、设备树、硬件时序、寄存器状态。结合日志、波形、调试工具缩小范围，找根因。
3. 本地验证修复
手写补丁修改问题点，本地单独编译内核/模块/设备树，测试，确认功能恢复、无副作用。同时验证异常场景、休眠唤醒、压力稳定性。
Patch 合入主线之前，需要先出临时版本，在产线压测 1-2 周，没问题再合入主线。
4. 整理提交补丁
按照内核规范写清晰的 commit 信息：现象、根因、修复方案、测试结果。
5. 合入仓库与版本发布
通过代码评审后，合入正式分支，更新版本基线、编译全新固件。记录问题单号、修复补丁、回归报告，归档交付，完成闭环。
总结：业余开发只做到“问题修好”，企业BSP 要做到可复现、可解释、可追溯、可迭代、可量产。也就是问题需要闭环，在公司里你会经常听到 “闭环” 这个词。这个流程也能避免你个人后续背锅，大厂里流程比个人魅力更重要。
大家还有什么想了解的，欢迎留言。
相关笔记
- 📁 返回本主题 MOC
- 从MCU转Linux BSP开发
- DDR替换后内核崩溃排查
- Linux编译视角调试方法
- Linux 调试手段，涵盖 printk 使用、动态打印、trace
- 嵌入式Linux调试iic
- 设备树反编译调试